With rapid technical advancements in recent years, wireless communication technologies have been utilized for increasingly diversified purposes. Utilization of media streaming services including video and/or audio, in particular, through mobile communication devices has increased. According to communication industries, it is expected that in the near future the mobile data traffic will grow explosively and the mobile video traffic will account for 70% of the total amount of the mobile data. Owing to explosive growth of mobile video traffic, users may experience network congestion.
Hence, a scheme is needed that can effectively deliver video/audio content through a mobile network. According to statistics of the video sharing site YouTube, the top 10 percent of popular video content accounts for nearly 80 percent of all video content traffic. Rather than delivering all video content at similar quality levels, delivering more popular video content at a higher quality level may effectively enhance user satisfaction.
HyperText Transfer Protocol (HTTP) Adaptive Streaming (HAS) has been introduced to deliver video traffic in an effective way. Examples of HAS implementation may include 3GPP (3rd Generation Partnership Project) 3GP-DASH (Progressive Download and Dynamic Adaptive Streaming over HTTP), Apple HTTP Live Streaming, and Microsoft Smooth Streaming.
FIG. 1 illustrates the architecture of a 3GP-DASH system serving as a HAS system. Here, although 3GP-DASH is used for illustration, similar approaches may also be applied to other HAS services.
Features of HAS may be described as follows.
1. Video content is divided into segments or chunks as units for transmission.
2. The HAS server maintains sets of video segments forming presentations, where different versions may be created for a video segment according to, for example, resolution.
3. A Uniform Resource Locator (URL) is assigned to each video segment. A terminal or client may access a desired video segment using URL and HTTP.
4. The HAS server maintains a metadata file containing information regarding the presentation of a source video, segment durations and segment URLs, and provides the metadata file to the client upon service initiation.
5. The client may select a video segment using a metadata file and request the selected video segment via a URL assigned to the video segment.
Referring to FIG. 1, the HAS server is implemented as an HTTP server 100. The HTTP server 100 maintains a Media Presentation Description (MPD) 110 and segments of a source video. The MPD 110 is a type of metadata described above. 3GP-DASH utilizes MPD as a metadata file format. The HTTP server 100 provides the MPD 110 to a DASH client 130. Later, when a request for a video segment is received from the DASH client 130 via HTTP, the HTTP server 100 provides the requested segment to the DASH client 130.
The DASH client 130 may include control heuristics 140, an MPD parser 150, a segment parser 160, a media player 170, and an HTTP client 180. The control heuristics 140 may control the overall operation of the DASH client 130. The MPD parser 150 may parse and analyze an MPD received from the HTTP server 100 and provide necessary information to the other components. In response to a request from the control heuristics 140 or other component, the HTTP client 180 may send a request for a segment as an HTTP request to the HTTP server 100. The HTTP client 180 may receive a video segment as a reply to the request from the HTTP server 100 and forward the received video segment to the segment parser 160. The segment parser 160 may parse the received segment and forward the parsed segment to the media player 170. The media player 170 may provide a control interface to the user, and play back the video segment received from the segment parser 160.
Two main advantages of HAS may be described as follows.
1. The streaming bitrate can be adjusted dynamically according to variations of network throughput.
2. Video streaming can be seamlessly provided to the user at the highest quality available.
FIG. 2 illustrates bitrate variations with time when HAS is used. Part (a) of FIG. 2 depicts bitrates of segments stored in the HTTP server 100 (i.e. HAS server). The HAS server maintains segments with first, second and third bitrates for corresponding time intervals.
Part (b) of FIG. 2 depicts variations in requested chunks or segments and TCP throughput. At the first time interval, the DASH client 130 (i.e. HAS client) may request a segment of the first bitrate. The HAS client may measure TCP throughput that is sufficient for a segment of the second bitrate at the first time interval; and the HAS client may request a segment of the second bitrate at the second time interval. The HAS client may measure TCP throughput that is sufficient for a segment of the third bitrate at the second time interval; and the HAS client may request a segment of the third bitrate at the third time interval. The HAS client may measure TCP throughput that is sufficient for a segment of the second bitrate but insufficient for the third bitrate at the third time interval; and the HAS client may request a segment of the second bitrate at the fourth time interval. Thereafter, while TCP throughput is sustained, the HAS client may request and process segments of the second bitrate and present the processed segments to the user.
Part (c) of FIG. 2 depicts variations in requested segments. As described above in connection with part (c) of FIG. 2, a first-bitrate segment is requested at the first time interval, and a second-bitrate segment is requested at the second time interval. A third-bitrate segment is requested at the third time interval, and a second-bitrate segment is requested at the fourth time interval and at the fifth time interval.
According to the HAS system described above, the HAS client utilizes the total available bandwidth as a TCP throughput estimation. The HAS client selects a presentation such as resolution and/or bitrate for the next segment on the basis of estimated TCP throughput. However, the HAS client cannot be accurately aware of network conditions of base stations or other network entities. Hence, the HAS client is unable to accurately measure the available bandwidth, causing the following problems.
1. Congestion: HAS clients requesting a bitrate higher than the bottleneck throughput may cause congestion.
2. Unfairness: when a HAS client selects a high bitrate and another client selects a low bitrate, the clients tend to maintain the selection unless the bottleneck bitrate is reached, causing unfairness.
3. Under-utilization: HAS clients operating in a conservative manner to avoid congestion may request segments of a bitrate lower than measured throughput, resulting in a poor utilization ratio below the bottleneck throughput.
In addition, as the HAS system operates in an end-to-end (e2e), the both ends cannot exert influence on other traffic passing the base station.
As the HAS client selects a bitrate and reports this to the HAS server, the HAS system may be slow to adapt to network changes.